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Project  Objectives,  Motivation,  and  Goals 


•  Modeling  &  Analysis 

■  Architecture-based  approach 

■  Generic  UML  structural  model 

-  Specific  models  instantiated  with  Architecture  Description  Language 


•  Previous  Work 

■  Verifying  our  approach  -  using  Jini  as  an  example 

•  Overview  of  On-Going  Work 

■  How  do  different  service  discovery  architectures  respond 
to  node  and  link  failures? 

■  How  can  these  responses  be  improved? 

•  Plans  for  Future  Work 
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Dynamic  discovery  protocols.. 

enable  network  elements  (including  software  clients  and  services,  and  devices): 

(1 )  to  discover  each  other  without  prior  arrangement, 

(2)  to  express  opportunities  for  collaboration, 

(3)  to  compose  themselves  into  larger  collections  that  cooperate  to  meet 
an  application  need,  and 

(4)  to  detect  and  adapt  to  changes  in  network  topology. 


NIST/ITL  role  in  supporting  industry ... 

In  the  future,  all  software  systems  will  be  distributed  systems  written  to 
operate  over  a  network,  where  conditions  vary. 

Dynamic  discovery  protocols  provide  a  foundation  upon  which  such 
distributed  systems  will  be  constructed. 

Understanding  the  current  (first)  generation  of  discovery  protocols  is 
essential  to  enable  industry  to  improve  designs  for  the  second  and 
subsequent  generations. 

Our  project  applies  architecture-based  analysis,  languages,  and  tools  to 

help  industry  improve  designs  and  specifications  for  service  discovery 
protocols  and  Architectural  Description  Languages  (ADLs)  and  tools. 
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DoD  Programs  Related  to  this  Project 

•  Fault  Tolerant  Networks  -  DARPA  Program 
http://www.darpa.mil/ito/research/ftn/index.html 


•  OpenWings  -  Joint  Motorola-Sun-U.S.  Army  Program  (key  enabler 
of  Joint  Vision  2020) 
http://www.openwings.org/index.htm 


•  Organically  Assured  and  Survivable  Information  Systems  (OASIS)  - 
DARPA  Program 

http://www.darpa.mil/ato/programs/oasis.htm 


•  Dynamic  Assembly  for  System  Adaptability,  Dependability,  and 
Assurance  (DASADA)  -  DARPA  Program 
http://www.darpa.mil/ito/research/dasada/index.html 


•  Critical  Infrastructure  Protection  (CIP)  and  High  Confidence, 
Adaptable  Software  (SW)  Research  Program  of  the  University 
Research  Initiative  (URI)  -  Office  of  Naval  Research 
http://www.onr.navv.mil/sci  tech/special/cipswuri/ 
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Our  Goal _ 

To  provide  metrics  and  approaches  to  compare  and  contrast  emerging 
dynamic  discovery  protocols,  to  better  understand  their  critical 
functions,  to  identify  weaknesses,  and  to  strengthen  the  robustness,  quality 
and  correctness  of  designs  for  future  protocols. 


Our  Overall  Technical  Approach 

•  Build  a  generic,  domain  model  (UML)  providing  consistent  terminology 
encompassing  a  range  of  service  discovery  protocols. 

•  Build  executable  models  of  service  discovery  protocols  from  extant 
specifications,  and  analyze  them  under  conditions  of  dynamic  change. 

•  Build  measurement  infrastructure  and  measure  implementations  of 
dynamic  service  protocols  for  scalability. 

•  Build  simulation  models  of  service  protocols  and  assess  the 
performance  of  such  models  in  the  face  of  dynamic  change. 

•  Design,  model,  and  evaluate  protocol  mechanisms  that  enable 
discovery  protocols  to  self-adapt  in  the  face  of  dynamic  change  (this  part 
of  the  project  is  funded  by  the  DARPA  Fauit  Toierant  Networks  program). 
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Presentation  Roadmap 


•  Project  Objectives,  Motivation,  and  Goals 


•  Modeling  &  Analysis 

■  Architecture-based  approach 

■  Generic  UML  structural  model 

-  Specific  models  instantiated  with  Architecture  Description  Language 

•  Previous  Work 

■  Verifying  our  approach  -  using  Jini  as  an  example 

•  Overview  of  On-Going  Work 

■  How  do  different  service  discovery  architectures  respond 
to  node  and  link  failures? 

■  How  can  these  responses  be  improved? 

•  Plans  for  Future  Work 
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Technical  Approach  Specific  to 

Architecturai  Modeiing  &  Anaiysis 


Model  Discovery  Protocol  specifications  using  Architecturai 
Description  Languages  (ADLs)  and  associated  tools 

Analyze  Discovery  Protocol  models  to  assess  consistency,  correctness, 
and  completeness  under  conditions  of  dynamic  change. 

Compare  and  contrast  our  models  with  regard  to  function,  structure, 
behavior,  performance,  complexity,  and  scalability  under  conditions  of 
dynamic  change. 
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Foundation  for  Comparisons:  A  Generic  Structurai  Modei 

(UML)  for  Service-Discovery  Domain 
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Architectural  Description  Languages  &  Toois.... 

•  Represent  essential  complexity  of  service  discovery  protocois 
with  effective  abstractions 

-  Rapide,  public-domain  ADL  and  toolset  developed  at  Stanford 
University  for  DARPA,  provides  ability  to  execute  architecture 
specifications,  producing  Partially  Ordered  Sets  of  Events  (POSETs) 
for  analysis. 

•  Provide  a  framework  and  context 

-  to  compare  and  contrast  dynamic  service  discovery  architectures 

-  to  define  metrics  that  yield  qualitative  and  quantitative  measures  of 
dynamic  component-based  software 

-  to  modei  alternate  approaches  to  specific  functions  or  mechanisms 
where  permitted  by  a  specification  or  where  a  specification  appears 
ambiguous 

-  to  help  pinpoint  where  inconsistencies  and  ambiguities  may  exist 
within  software  implementing  specifications  &  to  understand  how  such 
issues  arise 

•  Provide  our  work  to  ADL  purveyors  and  researchers  for  use  in 
improving  future  languages  and  tools 
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Architecture-based  Approach  to  Modeling  and  Analysis 

(using  Rapide,  an  Architecture  Description  Language  and  Toois 

Deveioped  for  DARPA  by  Stanford) 
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__!|«*************************************************** 

-**3.3  DIRECTED  DISCOVERY  CLIENT  INTERFACE  ** 

—  This  is  used  by  all  JINI  entities  in  directed 

—  discovery  mode.  It  is  part  of  the  SCM  Discovery 

-  Module.  Sends  Unicast  messages  to  SCMs  on  list  of 

-  SCMS  to  be  discovered  until  all  SCMS  are  found. 

—  Receives  updates  from  SCM  DB  of  discovered  SCMs  and 

-  removes  SCMs  accordingly 

—  NOTE:  Failure  and  recovery  behavior  are  not 

-  yet  defined  and  need  reviw. 

TYPE  Directed  Discovery  Client 

(SourcelD  :  IP  Address;  InSCMsToDiscover  :  SCMList;  StartOption  :  DD  Code; 
InRequestInterval :  TimeUnit;  InMaxNnmTries  :  integer;  InPV  :  ProtocolVersion) 

IS  INTERFACE 

SERVICE  DDC  SEND  DIR  :  DIRECTED  2  STEP  PROTOCOL; 

SERVICE  DISC  MODES  :  dual  SCM  DISCOVERY  MODES; 

SERVICE  DD  SCM  Update  :  DD  SCM  Update; 

SERVICE  SCM  Update  :  SCM  Update; 

SERVICE  DB  Update  :  dual  DB  Update; 

SERVICE  NODE  FAILURES  :  NODE  FAILURES;  -  events  for  failure  and  recovery. 
ACTION 

IN  Send_Requests(), 

BeginDirectedDiscoveryO; 

BEHAVIOR 

action  animation  lam  (name:  string); 

MySourcelD  :  VAR  IP  Address; 

PV  :  VAR  ProtocolVersion; 
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For  AM  (SM,  SD,  SCM): 

(SM,  SD)  IsElementOf  SCM  registered-services 
impMes  SCM  IsElementOf  SM  discovered-SCMs 

For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs  & 

(SD)  IsElementOf  SM  managed-services 
implies  (SM,  SD)  IsElementOf  SCM  registered-services 
For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs  & 

(SM,  SD)  IsElementOf  SCM  registered-services  & 

NOT  (SCM  IsElementOf  SM  persistent-list) 

implies  Intersection  (SM  GroupsToJoin,  SCM  GroupsMemberOf) 

For  All  (SM,  SD,  SCM,  SU,  NR): 

(SU,  NR)  IsElementOf  SCM  requested-notifications  & 

(SM,  SD)  IsElementOf  SCM  registered-services  & 

Matches((SM,  SD),  (SU,NR)) 
implies  (SM,  SD)  IsElementOf  SU  matched -services 


(CC3) 
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POSETs 


Assess  Correctness, 
Performance,  & 
Complexity 
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•  Modeling  &  Analysis 

■  Architecture-based  approach 

■  Generic  UML  structural  model 

-  Specific  models  instantiated  with  Architecture  Description  Language 


Previous  Work 

■  Verifying  our  approach  -  using  Jini  as  an  example 

•  Overview  of  On-Going  Work 

■  How  do  different  service  discovery  architectures  respond 
to  node  and  link  failures? 

■  How  can  these  responses  be  improved? 

•  Plans  for  Future  Work 
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Analysis  of  Jini  Using  Architecture-Based  Approach 

•  Architecture  depicts  network  topological  entities,  Jini 
entities  and  major  functions,  and  key  behavior 

•  Consistency  conditions  posit  state  relationships  a  protocol 
should  strive  to  maintain  among  functional  entities 

•  Scenarios  trigger  possible  sequences  of  events 
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Sample  Network  Topology  Applicable  to  JInl  Entitles 
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Layered  View  of  Prototype  JINI  Architecture  in  Rapide 

Derived  from  SEI  Architectural  Layers  Approach 
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Representing  Jini  Discovery  in  Terms  of  Our  Modei 


•  In  Multicast  Mode,  an  SU,  SM,  or  SCM 
will  try  to  discover  SCMs  that  are 
members  of  the  same  group  as  the 
discovering  entity. 

And  an  SU,  SM,  or  SCM  may 
dynamically  join  or  leave  groups 

•  In  Directed  Mode,  an  SU,  SM,  or  SCM 
will  try  to  discover  SCMs  that  are  on  a 
persistent  list  of  SCMs  to  be  discovered 
maintained  by  the  discovering  entity. 

And  SCMs  to  be  discovered  may  be 
dynamically  added  or  removed  from 

ihQ  persistent  list. 


1/31/2002 


16 


ITL  Pervasive  Computing  Portfolio 


NIST 


National  Institute  of  Standards  and  Technology 

Technology  Administration,  US,  Department  of  Connmerce 


1ST  CTNTEI 


Real-Time  Checking  of  Consistency  Conditions 


Sample  Consistency  Condition  #4  (race  condition) 


For  All  (SM,  SD,  SCM,  SU,  NR): 

(SU,  NR)  IsElementOf  SCM  requested-notifications  & 
(SM,  SD)  IsElementOf  SCM  registered-services  & 
Matches  ((SM,  SD),  (SU,  NR)) 

Implies  (SM,  SD)  IsElementOf  (S\J  matched-services) 


...that  is,  if  an  SU  has  requested  notification  with  a  Service  Cache  Manager  of  a 
service  that  matches  a  service  description  registered  by  a  Service  Manager  on 
the  same  Cache  Manager,  then  that  service  description  should  be  provided  to  the 
Service  User. 


Assuming  absence  of  network  failure  and  normal  delays  due  to  updates 


•  SM  is  Service  Manager 

•  SD  is  Service  Description 

•  SCM  is  Service  Cache  Manager 

•  SU  is  Service  User 

•  NR  is  Notification  Request 

1/31/2002 


•  requested-notifications  is  a  set  of  (SU,NR)  pairs 
maintained  by  the  SCM 

•  registered-services  is  a  set  of  (SM,SD)  pairs 
maintained  by  the  SCM 

•  matched-services  is  the  set  of  (SM,SD)  pairs 
maintained  by  the  SU 
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Should  the  Jini  Specification  Advise  about  Possibiiity  for 

Registration  Race  Condition? 
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implies  (SM,  SD)  IsElementOf  SU  matched-services 
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Real-Time  Checking  of  Consistency  Conditions 


Sample  Consistency  Condition  #3 


For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs 
(SM,  SD)  /sE/emenf  Of  SCM  registered -services 
NOT  (SCM  IsElementOf  SM  persistent-list) 

Implies  Intersection  (SM  GroupsToJoin,  SCM  GroupsMemberOf) 


...that  is,  if  a  Service  Manager  has  discovered,  and  registered  its  service 
descriptions  on,  a  Service  Cache  Manager  that  is  not  on  the  Service  Manager’s 
persistent  list,  then  the  Service  Manager  must  be  seeking  group  membership  in 
at  least  one  group  the  Service  Cache  Manager  belongs  to. 


Assuming  absence  of  network  failure  and  normal  delays  due  to  updates 


•  SM  is  Service  Manager 

•  SD  is  Service  Description 

•  SCM  is  Service  Cache  Manager 
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•  registered -services  is  a  set  of  (SM,SD)  pairs 
maintained  by  the  SCM 

•  discovered-SCMs  is  a  set  of  SCMs  discovered 
by  the  SM 

•  Persistent-list  is  the  set  of  SCMs  the  SM  is 
seeking  though  directed  discovery 
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What  Might  Happen  When 
SCM  Changes  Group  Membership  Dynamicaiiy? 


(CC3) 


For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs  & 

(SM,  SD)  IsElementOf  SCM  registered-services  & 

NOT  (SCM  IsElementOf  SM  persistent-llst) 

implies  Intersection  (SM  GroupsToJoin,  SCM  GroupsMemberOf) 


1/31/2002 


20 


ITL  Pervasive  Computing  Portfolio 


NIST 

National  Institute  of  Standards  and  Technology 

Technology  Administration,  US,  Department  of  Commerce 


NtST  CENTENNIAL 


^^myARDj^ 


Real-Time  Checking  of  Consistency  Conditions 


Sample  Consistency  Condition  #1 

For  All  (SM,  SD,  SCM):  (SM,  SD)  IsElementOf  SCM  registered-services 

implies  SCM  IsElementOf  SM  discovered-SCMs 

...that  is,  a  Service  Manager  shouid  register  its  Services  on  an  Service 
Cache  Manager  only  if  it  maintains  that  Cache  Manager  on  its  “known 
SCM”  List. 


^Assuming  absence  of  network  failure  and  normal  delays  due  to  updates 


•  SM  is  Service  Manager 

•  registered-services  is  a  set  of  (SM,SD)  pairs 

•  SD  is  Service  Description 

maintained  by  the  SCM 

•  SCM  is  Service  Cache  Manager 

•  discovered-SCMs  is  a  set  of  SCMs  discovered 

by  the  SM 

Same  executable  model  can  be  used  to  assess  selected  performance 
properties  and  to  measure  complexity* 


|*future  work  on  the  project  intends  to  investigate  the  relationship  between  design  complexity  (applying 
ideas  from  Kolmogorov  Complexity)  and  design  quality  (as  represented  by  violation  of  consistency 
conditions) 

1/31/2002  21 


ITL  Pervasive  Computing  Portfolio 


NIST 


National  Institute  of  Standards  and  Technology 

Technology  Administration,  US,  Department  of  Commerce 


1ST  C  T 


5\RDA^ 


Could  the  Jini  Specification  Lead  to  Implementations  Exhibiting 
Undesired  Interaction  between  Directed  and  Multicast  Discovery? 


Scenario 

SM4 

SCM3 

GroupJoin  GROUP2 


Probe  SM2  GROUP2 


Based  on  one 
possible 
interpretation  of 
specification  using 

a  single-list 
assumption 


Discovered  SCMs 
(SCM3) 


GroupLeave  GROUP2 


AddSCM  SCM3 


Discovered  SCMs 
(SCM3) 


No  Dupiicates  Allowed 


Discovered  SCMs 
0 


Found  SCM3  GROUP2 
Register  SM4  SD1 
Discover  SCM3 


Registered  Services 
(SM4,  SD1) 


Registered  Services 
0 


Registered  Services 
(SM4,  SD1) 


Lease  Expired 
SM4  SD1 


Registered  Services 

() _ 


^onsistenc^_Restore^ 

ForAII(SM,sb,SCM): 

(SM,  SD)  IsElementOf  SCM  registered-services  (CC1) 
implies  SCM  IsElementOf  SM  discovered-SCMs 


J 
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Real-Time  Checking  of  Consistency  Conditions  (con’t) 


Sample  Consistency  Condition  #2 


For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs  & 

SD  IsElementOf  SM  managed-services 

Implies  (SM,  SD)  IsElementOf  SCM  registered-services 


...that  is,  a  Service  Manager  should  register  its  Services  on  an  Service 
Cache  Manager  if  the  Service  Manager  has  discovered  the  Cache 
Manager  and  is  maintaining  the  SCM  identifier  on  its  “known  SCM”  List. 


"^Assuming  absence  of  network  faiiure  and  normai  deiays  due  to  updates 


•  SM  is  Service  Manager 

•  SD  is  Service  Description 

•  SCM  is  Service  Cache  Manager 


•  discovered-SCMs  is  a  set  of  SCMs  discovered 
by  the  SM 

•  managed-services  is  a  set  of  (SM,SD)  pairs 
maintained  by  the  SM 

•  registered-services  is  the  set  of  (SM,  SD)  pairs 
maintained  by  the  SCM 
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Could  the  Jini  Specification  Lead  to  Implementations  Exhibiting 
Undesired  Interaction  between  Directed  and  Multicast  Discovery? 


Scenario 

SM4 

SCM1 

Based  on  a  second 
possible 
interpretation  of 
specification  using 

separate-list 

assumption 


AddSCM  SCM1 


Discovered  SCMs 
MD() 

DP  (SCM1) 


Disrnvpr  SOMI 


GroupJoin  GROUP1 


Registered  Services 
(SM4,  SD1) 


Discovered  SCMs 

•  ^ - -  ,  ► 

^  - -  • 

Registered  Services 

MD  (SCM1) 

^ ^ 

+ :  : 

0 

DD  (SCM1) 

L _ Register  SM4  SD1 

GroupLeave  GROUP1  ^ 


Discovered  SCMs 
MD() 

DP  (SCM1  ) 


I 


Registered  Services 
(SM4,  SD1) 


Registered  Services 
0 


Cancelled  SM4  SD1 


CC2  Violated 


For  All  (SM,  SD,  SCM): 

SCM  IsElementOf  SM  discovered-SCMs  &  (CC2) 

(SD)  IsElementOf  SM  managed-services 

implies  (SM,  SD)  IsElementOf  SCM  registered -services 
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Presentation  Roadmap 


^RDA^ 


•  Project  Objectives,  Motivation,  and  Goals 


•  Modeling  &  Analysis 

■  Architecture-based  approach 

■  Generic  UML  structural  model 

-  Specific  models  instantiated  with  Architecture  Description  Language 


Previous  Work 

■  Verifying  our  approach  -  using  Jini  as  an  example 


Overview  of  On-Going  Work 

■  How  do  different  service  discovery  architectures  respond 
to  node  and  link  failures? 

■  How  can  these  responses  be  improved? 


•  Plans  for  Future  Work 
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How  do  Two-  and  Three-Party  Architectures  for 
Service  Discovery  Respond  to  Faiiures? 


•  Two-Party  vs.  Three-Party  architectures 

Two  alternative  architectural  designs  that  underlie  commercial  service 

discovery  protocols,  including  Jini,  UPnP,  and  Service  Location  Protocol 

•  Impact  of  Study: 

1 .  Provide  valuable  information  to  designers  and  users  of  service 
discovery  protocols  for  improving  specifications,  thus  promoting 
software  quality  and  reliability. 

2.  Create  generic  set  of  test  scenarios  and  related  metrics  that 
companies  can  use  when  developing  products 

3.  Provide  recommendations  on  improving  ADLs 
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Selected  Current  (First)  Generation 
Protocols  for  Dynamic  Service  Discovery 


Universal 


Jin  I  Plug  and  Play 


3-Party  Design  2-Party  Design 


•i  WILEY 


SLP 

for  Enterprise 
Networks 


Implement  iiiR  mul 
Deployinj?  a  Dynamic 
Resoiux*e  Finder 

% 

Rnbort  S<.  PiMTP 
JaiiM-i  Ki'inpr 


Adaptive  2/3-Party  Design 


The 

Salutation 

J  Consortium,^ 

* 

m 

*4  “4  • 

• 

M  M 

Verticaliy  Integrated 
3-Party  Design 


Network-Dependent 
3-Party  Design 


©  Bluetooth  " 


Network-Dependent 
2-Party  Design 
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Two  Party  vs.  Three  Party  Architectures 

Party 


SERVICE  MANAGER 
discover  Network  Context() 

|«not  shr»  Cache  Manager  Discovery() 

|«OPT»  Announce  Service  Processing() 

|«not  shr»  start  Renewal  Task() 
srvice  Manager() 

:not  shr»  start  Service  Parameter  Matching  Task() 


service  information  collection 

SERVICE  CACHE  MANAGER 

0..* 

^discover  Network  Context() 

1 

\ 

+info  cache 

H«not  shr»  activate  Manager  Discovery() 
^activate  Announce  Processing() 

^start  Matching  Task() 

^start  Aging  Task() 

^Service  Cache  Manager() 

Service 

Cache 

V 

S  ©  1  Conta^s  Contmns 

Manager 

Service 
Description 


Notification 

Cache 


Notification 

Request 


Parameter 
Change 
Notification 
Cache 


«repository  entry» 
Parameter  Notification  Request 

(from  Data  View) 


Parameter 

Change 

Notification 

Request 


0.4 

LOCAL  CACHE  MANAGER 

1 

♦ - > 

«repository» 

|Start  Aging  Task() 

Service  Cache 

\ 


Local 

Cache 

Manager 


Service 

Cache 


\ 
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Layered  View  of  Prototype  UPnP  Architecture  in  Rapide 


Derived  from  SEI  Architectural  Layers  Approach 
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How  Do  Service  Discovery  Architectures  Propagate 

Changes  During  Link  Faiiure? 

Change  Propagation:  In  both  two-party  and  three-party  architectures 
changes  in  critical  characteristics  of  Service  Descriptions  (SDs)  must 
propagate  from  Service  Managers  (SMs)  to  Service  Users  (SUs)  that 
already  hold  copies  of  the  SDs. 

•  Change  propagation  may  take  place  through  polling,  eventing,  or  ad- 
hoc  announcements  -  How  do  these  strategies  compare? 

•  Does  the  existence  of  a  third  party  (i.e..  Service  Cache  Manager,  or 
SCM)  improve  or  hinder  performance? 

Approach:  develop  a  series  of  failure  test  scenarios  and  metrics  for 
comparing  and  contrasting  the  alternative  architectures  with  regard  to 

•  Amount  of  inconsistent  time  -  sum  of  time  that  SM^(SDj)  not  equal 
to  SUj(SDi)  for  all  i,  j,  k 

•  Change  propagation  iatency  -  time  delay  from  [SM^(SDj)  not  equal  to 
SUj(SD^]  until  ISM^(SD)  equal  to  SU/SD^] 

•  Change  propagation  overhead  -  number  of  messages  in  interval 
from  [SMi^(SDj)  not  equal  to  SUj(SDj)]  until  [SMi^(SDj)  equal  to  SUj(SDj)] 
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How  Do  Service  Discovery  Architectures  Recover 
Consistency  After  Link  and  Node  Faiiures? 

Discovery  and  Recovery:  In  both  two-party  and  three-party  architectures, 
SMs,  SUs,  and  SCMs  (where  applicable)  strive  to  maintain  consistent 
descriptions  (SDs)  about  discovered  services  and  about  event  notifications. 
Link  and  node  failures  may  lead  to  temporary  loss  of  information  about 
discovered  services.  Once  failures  are  repaired,  the  information  must  be 
recovered. 

We  seek  to  develop  metrics  to  compare  and  contrast  different  service- 
discovery  architectures  and  specifications.  For  example: 

•  How  do  discovery  latencies  and  overheads  compare? 

•  How  do  event  registration  latencies  and  overheads  compare? 

•  How  do  recovery  latencies  and  overheads  compare? 
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Can  the  Response  of  Service  Discovery 
Processes  Be  improved? 

•  Emerging  designs  for  military  fault-tolerant  systems  (e.g.,  OpenWings, 
OASIS,  CoABS)  rely  on  discovery-based  component  architectures  to 
enable  self-organizing  and  self-healing  behavior 

•  The  discovery  protocols  underlying  such  systems  include  mechanisms  that 
permit  network  elements  to  continue  to  function  as  the  topology  varies 

•  However,  many  performance  aspects  of  these  protocols  appear  sensitive 
to  parameter  settings  whose  optimum  values  depend  upon  network 
topology 

•  Such  parameters  may  be  manually  configured  and  tuned  in  relatively 
small,  static  environments,  but  their  management  in  larger,  highly 
dynamic  environments  cannot  be  performed  manually 
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Investigating  If  Improvements  Can  Be  Achieved 

Through  Self-Adaptation 


•  Model  and  analyze  protocols  (UPnP,  Jini,  or  SLP)  as  specified 

■  develop  SLX  simulation  models  for  each  protocol 

■  establish  performance  benchmarks  based  on  default  or  recommended 
parameter  values  and  on  required  or  most  likely  implementation  of  behaviors 

•  investigate  distributed  adaptation  aigorithms  to  control  parameter 
values  (and  also  consider  selected  adaptive  behaviors) 

■  devise  several  algorithms  to  adjust  control  parameters  in  each  protocol 

■  compare  performance  of  each  algorithm  against  benchmark  performance 

■  select  most  promising  algorithms  for  further  development 

•  impiement  and  vaiidate  seiected  aigorithms  in  publicly  available 
reference  software 


modify  available  implementation  of  UPnP,  Jini,  or  SLP 

deploy  in  service-discovery  test  bed  (now  under  development  at  NIST) 

validate  simulated  results  with  live  experiments 
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Presentation  Roadmap 

•  Project  Objectives,  Motivation,  and  Goals 

•  Modeling  &  Analysis 

■  Architecture-based  approach 

■  Generic  UML  structural  model 

-  Specific  models  instantiated  with  Architecture  Description  Language 

•  Previous  Work 

■  Verifying  our  approach  -  using  Jini  as  an  example 

•  Overview  of  On-Going  Work 

■  How  do  different  service  discovery  architectures  respond 
to  node  and  link  failures? 

■  How  can  these  responses  be  improved? 


•  Plans  for  Future  Work 
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Extending  Generic  UML  Modei  to  Encompass  Message 

Exchanges  and  Assertions 


•  Can  the  messages  exchanged  among  classes  in  our  UML 
structural  model  be  unified  into  a  common  vocabulary  of  message 
types  and  message  attribute  values? 

•  Can  consistency  conditions  and  other  assertions  be  defined 
based  on  our  unified  structural  and  message-exchange  models? 

•  Can  consistency  conditions  be  expressed  to  include  temporal 
clauses  that  precisely  bound  the  duration  of  any  temporary 
inconsistencies  permitted  by  a  discovery  protocol? 

•  Can  these  unifications  be  carried  into  our  ADL  model  of  specific 
discovery  protocols,  so  that  differences  among  the  various 
architectures  can  be  compared  more  directly? 
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Investigating  Applicability  of  Architectural  Models 

to  Measure  System  Complexity 


•  Using  the  unified  architectural  models,  create  representations  of 
various  complexity  metrics  proposed  in  the  literature,  such  as 
algorithmic  information  complexity. 
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To  Delve  More  Deeply 

Currently  Available  Paper 

•  Christopher  Dabrowski  and  Kevin  Mills,  “Analyzing  Properties  and 
Behavior  of  Service  Discovery  Protocols  using  an  Architecture-based 
Approach”,  accepted  at  DARPA-sponsored  Working  Conference  on 
Complex  and  Dynamic  Systems  Architecture,  to  be  held  December  2001 . 

Available  Software  Artifacts 

•  Generic  UML  Structural  Model  (in  Rational  Rose  format)  of 

Discovery  Protocols,  including  specific  projections  to  Jini,  UPnP,  and  SLP 

•  Rapide  Models  of  Jini  and  UPnP  {in  progress). 

•  SLX  Simulation  Model  of  UPnP  (in  progress). 

Related  Web  Sites 

•  http://www.itl.nist.qov/div897/ctq/adl/sdp  proiectpaqe.html 

*  http://w3.antd.nist.qov/net  pc.shtml 
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Model  &  Analyze  SDP  Function,  Structure,  and  Behavior 


Objectives 

(1)  Provide  increased  understanding  of  the  competing 
dynamic  discovery  services  emerging  in  industry 

(2)  Develop  metrics  for  comparative  analysis  of 
different  approaches  to  dynamic  discovery  and  assuring 
quality  and  correctness  of  discovery  protocols 

(3)  Assess  suitability  of  architecture  description  languages  to 
model  and  analyze  emerging  dynamic  discovery  protocols 

Technical  Approach 

Develop  ADL  models  from  selected  specifications  for  service 
discovery  protocols  and  develop  a  suite  of  scenarios  and 
topologies  with  which  to  exercise  the  ADL  models 
Propose  a  set  of  consistency  conditions  &  constraints  that 
dynamic  discovery  protocols  should  satisfy 
Propose  a  set  of  metrics,  based  on  partially  ordered  sets, 
with  which  to  compare  and  contrast  discovery  protocols 
Analyze  ADL  models  to  assess  consistency  condition 
satisfaction,  and  to  compare  and  contrast  protocols 


Recent  Accomplishments: 


Products  &  Contributions 


•  Developed  a  generic  UML  model  encompassing  the 
structure  and  function  of  Jini,  UPnP,  SLP,  Bluetooth, 
and  HAVi 

•  Projected  specific  UML  models  for  Jini,  UPnP,  and  SLP 

•  Completed  a  Rapide  Model  of  Jini  structure,  function, 
and  behavior 

•  Drafted  and  implemented  a  scenario  language  to  drive 
the  Rapide  Jini  Model. 

•  Developed  a  set  of  consistency  conditions  and 
constraints  for  Jini  behavioral  model;  currently  being 
tested  using  scenarios. 

•  Discovered  significant  architectural  issue  in  interaction 
between  Jini  directed  discovery  and  multicast  discovery 


•  Rapide  specifications  of  Jini,  Universal  Plug  and  Play 
(UPnP),  and  Service  Location  Protocol  (SLP) 

•  Scenarios  and  topologies  for  evaluating  discovery  protocols 

•  Suggested  consistency  properties  for  service  discovery 
protocols 

•  Suggested  metrics,  based  on  partially  ordered  sets 
(POSETs),  for  comparing  and  contrasting  discovery  protocols 

•  Paper  identifying  inconsistencies  and  ambiguities  in  service 
discovery  protocols  and  describing  how  they  were  found 

•  Paper  proposing  consistency  conditions  for  service  discovery 
protocols,  and  evaluating  how  Jini,  UPnP,  and  SLP  fare 

•  Paper  comparing  and  contrasting  Jini,  UPnP,  and  SLP  at 
the  level  of  POSET  metrics 
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